Tracking business processes traditionally is a data-oriented activity. This makes sense: processes are all about manipulating data, so orienting the process around how the data are tracked is an intuitive solution. For example, consider an organization chart. As shown in FIG. 1, organization chart 105 typically includes a chief executive officer 110, along with other officers not shown in FIG. 1. Eventually, somewhere down the hierarchy, are the departments. FIG. 1 shows three departments: Department A 115, Department B 120, and Department C 125. Each department includes some employees, shown by employee lists 130, 135, and 140, respectively.
Now consider what happens when an employee changes department. For example, consider Employee 5 moving from Department A 115 to Department B 120, as shown by arrow 145. Traditionally, Employee 5 is deleted from employee list 130 and added to employee list 135.
But what if Employee 5 was the only employee who worked on a project assigned to Department A 115 when Employee 5 was with Department A 115? If the project is assigned back to Employee 5, it will be associated with Department B 120, which does not have any familiarity with the project. The wrong department (Department B 120) will be working on the project.
Data changes, such as moving Employee 5 from Department A 115 to Department B 120, typically requires authorization. If authorization and the data change process are tracked at all, the information about the data change is stored as part of the data object. For example, the employee information can store who authorized a promotion or additional training for an employee. But data changes are tracked only in very limited cases, requiring special-purpose implementation every time such information is to be stored. Additionally, the data change information is usually incomplete. Finally, typically the lifecycle of the data change authorization is not tracked.
The present invention addresses these and other problems associated with the prior art.